Ahoy 1987 May/Ahoy_Magazine_87-05_1987_Double_L_Side_B.d64/star trek.txt

Text File | 1987-01-01 | 6.7 KB | 241 lines

STAR TREK DATA BASE

by Len Lindsay

I wanted to write a program to
demonstrate file handling, especially
with random files. Star Trek
presented itself as an excellent
topic. This science fiction show has
been on the air for 20 years now,
with a total of 79 episodes. I
created a data base system that can
easily keep track of all of these
shows. Very little in this data base
is specific to Star Trek.

I used 8 fields of 27 characters each
to store the data for a show, plus
two extra fields that you can decide
how to use. The titles for each of
the 8 main fields can vary depending
on what information you wish to keep
track of. For my Star Trek shows I
chose the following:

Show Name :
Writer    :
Air Date  :
Guest Star:
          :
Characters:
          :
Location  :

I've also provided two extra "user"
fields. The first is an "Star Date"
of 6 characters. Currently the star
date that is mentioned (if any) is
entered, but you could put the video
tape number here, the name of your
friend who has this show on tape, or
a short comment on the show. The
other field is only one character. It
can be used to rate each show (A,B,C,
etc). I use it to mark the shows that
I have seen. If marked, the entire
show is shown in reverse (white on
black).

Charles Phillips was nice enough to
type in all 79 episodes. Once you
have a data base filled with
information, it is easy and fun to
use.

For example, let's say your favorite
author is Harlen Ellison. Using the
data base system, you can choose the
Search option, and it will list every
show written by him. The nice thing
about this is that the system uses
COMAL's IN operator to find the
matches. Thus, you can ask the system
to look for "ar" and it will find
both Harlen Ellison and David
Garrold. Remember, the search is very
picky on upper or lower case. Thus,
Cyb will not match CYB.

Since this system uses a random file
for its data, it is easy to randomly
display any show. Just type in the
show number, and instantly (almost)
its information is displayed. To see
the next show just type + (plus
sign). To see the previous show type
- (minus sign).

Another nice feature of this system
is BROWSE. It allows you to scan over
all the entries, one after another,
starting after the show currently
displayed. It even has a variable
pause between shows. Five seconds is
the default, but for a fast scan, use
0 for the length of pause.

NOTES ABOUT THE PROGRAM

The variable mark$ is used to
determine whether or not the
information display is normal or
reverse field. The seventh line of
the program is:

display(mark$<> " ")

Display is the name of the procedure
that prints the information about the
show to the screen. It has one
numeric parameter. If the parameter
is FALSE (a value of 0) then the
information is displayed normally. If
it is TRUE (a value not equal to 0)
then the information is displayed in
reverse field. Mark$<> " " is a
comparison that will always be either
TRUE or FALSE, thus providing the
proper parameter.

Notice that to have the reverse
display, each value printed must be
the correct length because the
reverse field will stop at the last
character. The length used in this
program is 27. Thus, if the show name
is less than 27 characters, I had to
do something to print reverse field
spaces at the end of the name. I let
COMAL take care of this for me by
using substring notation when
inputing this data (from both
keyboard input and file input). For
example:

dim name$ of 27
input "name:": name$
print chr$(18)+name$
print "length is";len(name$)
input "name:": name$(1:27)
print chr$(18)+name$
print "length is";len(name$)

Run that program and type TEST as the
name both times it asks. The first
time it has a length of 4. The last
time it has a length of 27 (the value
was padded with spaces at the end).
Printing it each time in reverse
field shows how the (1:27) takes care
of formatting problems for me!

Calculating the correct record length
is also important when using random
files. Use the maximum possible
length as the length for the file. In
this case I had 8 fields of 27
characters, 1 field of 11 characters,
and 1 field of 1 character. Since
each field is a string, I also must
add a 2 byte counter for each field.
Thus 8*29 plus 13 plus 3 gives 248.
The smallest record size I can use
and be sure to hold all possible data
is 248, which I set in the start'up
procedure.

To calculate record length when using
WRITE FILE remember these rules:

* A real number always needs 5 bytes
* An integer needs 2 bytes in COMAL
2.0
  An integer needs 5 bytes in COMAL
0.14
* A string needs its maximum length
  PLUS 2 bytes for a length counter

Knowing how many records have been
written is also important when using
random files. If you attempt to read
a record past the last existing one,
an error occurs! A common way to keep
track of the last record number is to
WRITE it into the first record of the
file:

write file 2,1: last'record

Last'record is a variable that holds
the number of the last record written
to the file. Now, each time you use
that file, you can simply read the
last record number from the file like
this:

read file 2,1: last'record

The only side effect of this is that
you cannot use the first record for
regular data. Often, this is not a
problem. For example, in our order
processing system programs (running
under IBM PC COMAL) COMAL Today
subscribers are part of a random
file, stored by their subscriber
number. Since I use the first record
to hold the last subscriber's number,
I started my subscriber count with 2.
Thus there is no subscriber number 1.

But in keeping track of Star Trek
shows, there is a show number 1.
Since it can't be written into record
number 1, we simply add 1 to the show
number to give the record number
(read this sentence twice - it makes
sense). Thus show number 1 is stored
in record number 2. Both read'record
and write'record procedures do the
record number conversion.

Another thing I try to do is keep my
files closed as much as possible. On
a Commodore disk, all files must be
properly closed or they can't be
opened later. So, I take precautions
(in case of a power outage etc.) and
keep the file closed when it is not
directly being used. For example,
while searching the file for matches,
I use the procedure read'record
directly, and don't close the file
after each record is read. I only
close the file after I find a match.
However, when just getting
information about one show, I have
the procedure read'it which first
opens the file, then reads the
record, then closes the file. Thus
the file is closed while I look at
that record (and possibly edit it).
Note that I always close the file
after I write to it. Thus I only have
one write'record procedure.

Remember, the data is one of the most
important parts of this data base
system! The data is in the file
"ran.startrek".